Instead of inserting keys into the bloom filter one by one as they are
added to the run accumulator, save them up and add them all in one go
when the page is being finalised.

This then lets us use a bloom filter bulk insert, which lets us use
memory prefetching.

The result should be faster.

Fetch into the caches in the least intrusive way, "0" levels, rather
than "3" levesl. This does not appear to slow down inserts, and should
evict fewer things from the caches.

And document what level "0" means and why we use it.

`bloomQueriesModel` was not really a proper model, because the model itself was
using actual bloom filters. The model is now instead a `Set`, and
`prop_bloomQueriesModel` is updated because the model will now only return true
positives and negatives.

Previously, for the Classic Bloom filter implementation we had two
different implementations of bloomQueries: one that was relatively
simple and didn't rely on anything fancy, and one that went all out to
maximise performance.

The high performance one had to be disabled when we added the
block-structured bloom filter implementation, since it was tightly
coupled to that implementation.

With the new bloom filter API and implementation, we can now implement a
single high performance version of bulk query. We no longer need
separate higher and lower performance versions, since we no longer need
to rely on fancy features like unlifted boxed arrays.

So strip out the bloom-query-fast cabal flag and the BloomFilterQuery2
module.

The updated BloomFilterQuery1 does a simple nested loop: iterating over
all filters and within that over all keys. It does two loops over the
keys: one to prefetch the key for the filter, and a second one to do the
lookups for real. Thus the prefetch distance is the number of keys,
which is of course somewhat variable. In benchmarks this version was
slightly faster than nesting the loops the other way around, but perhaps
the other way around would have more stable prefetching behaviour over a
wider range of key batch sizes. Changing this would not be too hard.

The query module used to be big, and there used to be two of them. Now
there's only one and it's a lot smaller. So it makes sense to keep it
all together in one module.

We were using a mix of import qualified as BF, and import as Bloom.

This means our prefetching is done with a prefetch distance of the
number of runs, which is more stable than the key batch size.

Also tweak the code so we get only joinrec and not letrec in the core.